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REMARKS 

This responds to the advisory office action of 3 July 2008 which refused to enter 
applicants' reply of 24 June 2008. The attached RCE is filed to continue prosecution of 
this application. It is requested that the reply of 24 June 2008 be entered into the 
application. It is also requested that the attached amendment filed with the RCE be 
entered to facilitate continued prosecution. 

Claims 1 and 3-13 were rejected under 35 USC 102(b) as anticipated by Noble 
(US patent 5,845,128.). This amendment revises claims 1, 4-5, and 7-13. Claims 3 and 
6 previously presented. Claims 2 and 14-17 were priorly cancelled. Claims 1 and 3-13 
remain for reconsideration. The attached claims are presented in a format wherein the 
amendatory d ele t i ons and additions are made with respect to a "clean" version of claims 
in their 24 June 2008 amendment. 

All rejections are traversed. 

Noble and Applicants' disclosures both relate to releases of software. There are 
many differences between Noble and the Applicants' disclosure. Applicants generate a 
new generic software release by creating a new version of software in a build area and 
comparing the new software with existing software in a release area. Noble is solely and 
exclusively directed to the creation of customized software releases for customers 
having special needs. Each release is unique to the customer for whom it was created. 

After revising the software in the build area, the Applicants use further facilities 
and method steps to validate and transfer the modified software from the build area 106 
to release area 108 to define the entirety of a new software release. Applicants system 
includes: a scan element 302 that determines the revised software stored in the build 
area 106; the generation of an inventory file 310 using the scanned generic software in 
the build area 106; operating the inventory file 310 to compare software in the build area 
106 with the prior version of the software in the release area 108; operating a software 
release information manager 300 to compare the build information in the inventory file 
with the software comprising a current release of the files stored in the release area 
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108. After the comparison is made, the software information release manager and 
install module 306 are configured to install the modified software from the build area 
106 to the release area 108 to create the entirety of a new generic software release. 

Applicants' dependent claims recite that a software release information manager 
comprises a release database coupled to a scan element and an inventory file; a verify 
element coupled to the inventory file to compare software information in the release 
area with the corresponding information in the build area; install element 308 coupled to 
the inventory file 310 copies software from the build area 106 to the release area 108; 
and the build area is used by a developer to modify or create new versions of generic 
software for distribution to the release area as a revision/replacement for the existing 
version of the generic software stored in the release area. 

Noble is not concerned with modifying existing generic software for a new 
generic release. Noble's figure 3 discloses an old release subdirectory 202 as well as a 
new release subdirectory 204. However, Noble figure 3 does not modify the old release 
subdirectory 202; nor does he apply the old release 202 to the new release subdirectory 
204. The non-customize portions of Noble elements 202 and 224 are purchased from 
an outside vendor. See Noble's disclosure, column 6 lines 1-11. 

Noble in not a valid anticipation since it does not teach all elements of applicants' 
claims as required for 35 USC 102(b) rejections. Noble fails to meet the 35 USC 102(b) 
requirements that an anticipatory reference must possess. A review of section 2131 of 
the MPEP is instructive. Section 21 31 .01 states that in order to anticipate a claim; a 
single primary reference must be found that teaches every element of the rejected 
claim. The well known "all elements" rule requires that the identical invention must be 
taught by the reference asserted to be anticipatory and must be in as complete detail as 
is contained in the claim being examined. For anticipation, there can be no difference 
between the claimed invention and the reference disclosure. The reference disclosure 
must be understandable and enabling to a person of ordinary skill in the field of the 
invention . Also, the MPEP also requires that the identical invention disclosed by the 
single reference must be shown in as complete detail as contained in the rejecting 
claim. Further, the elements of the reference must be arranged as required by the claim. 
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Noble does not meet this requirement. The elements of Noble relied upon by the 
Examiner for this rejection are scattered throughout Noble with no consideration being 
given by the Examiner to whether the Noble elements are arranged as required by a 
rejected claim. The Examiner's rejection and relies on Noble elements with no 
consideration being given to them MPEP requirements. Therefore, in view of these 
above stated multiple deficiencies, the Examiner's rejection based upon anticipation by 
Noble is without merit and cannot be supported. 

The 35 USC 1 02(B) Rejections of Claims 1 and 3-1 3 

Applicants' amended independent claim 1 recites a software release inventory 
file, a build area, a scan element which together are effective in controlling the transfer 
of software from a build area to a release area. Claim 1 also recites an inventory file that 
is operative in the transfer of software to the release area. This is a not shown or taught 
by Noble. The material Noble relied on by the Examiner has been studied and, to the 
extent it can be understood, has no relevance to the amended claim 1 . 

Noble does not disclose a build area. The reason for this is that he does not 
generate non-customized software. By his own admission, he purchases generic 
software from outside vendors. Thus, Noble has no need for a build area in which 
generic software is created for subsequent transfer as the entirety of a new release to a 
release area. The customized software that is transferred by Noble to a release area 
204 is derived from end-users customization of their existing software in element 202. 
Noble customizes software in element 202 is combined with the generic software 
purchased by Noble. The new customized software generated by the end-user in 
element 202 is transferred to a subdirectory 206 and then transferred, if required, to 
Noble's new release subdirectory 204. Those skilled in the art will realize that Noble 
does not transfer generic software from older release element 202 to a new release in 
element 204. Those skilled in the art will also recognize that Noble is sole function is to 
transfer customer generated custom izations between different revision of his software to 
accommodate the unique needs of each end user. 
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The build area of claim 1 (not shown by Noble) is followed by the elements and 
functions of the build area. Applicants' do not agree with the Examiner's analysis of the 
build area. The Examiner cites the material in column 4 lines 45-65, column 5 lines 7- 
10, and column 6 lines 1-15 as being anticipatory. Applicants' disagree. The material in 
Noble column 5 lines 7-10 does not teach the details of provide a virtual copy of an 
original file. This material does not anticipate or teach the corresponding elements 
recited amended claim 1 . 

The old directory 202 of Noble; it is not a build area. Noble buys the generic 
software and the user adds the customization to directory 202. The database tool set is 
not an inventory file, does not copy customized software. It provides access for the 
purchased software, which is already built. It is not a build utility. It is not involved in 
transferring customized files to the new release subdirectory 204. 

The Applicants' software release information manager (SRIM) of claim 1 recites 
the details and functions of applicants' SRIM 300. The Examiner cites column 7, lines 5- 
67 and column 8, lines 1-60 in support of his rejection. Applicants disagree. Claim 1 
recites the elements to which SRIM 300 is connected, as well as the functions 
performed by these elements, together with the functions of SRIM 300 in copying files. 
The Examiner's cited material is inadequate. It does not teach the details of elements, 
including a build area, including transferring the entirety of a new software release from 
the build area to the release area. 

Claim 1 recites including how the SRIM controls the operation of the inventory file 
and the scan element to effect a transfer of new software release from the build area to 
the release area to define the entirety of a new release. The Examiner cites Noble's 
column 8, lines 3-10. This material does not support the Examiner's comments. Noble 
does not teach the recited scan element or the build area. 

Claim 1 also recites an inventory file that receives and stores information in the 
build area. This recitation is followed by the functions performed by the inventory file 
under control of a scan element to compare all files comprising the build area area. The 
Examiner cites the Noble material of column 7, line 43 through column 8, and line 55. 
This does not to support the Examiner's position. It does not disclose elements that 
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teach the functions of the Applicants' recited inventory file. 

The Examiner's comments regarding the software release information manager 
is traversed. Contrary to the Examiner's assertion, the customized files are not 
transferred from the old release subdirectory 202 to release subdirectory 204. Instead, 
the customized files are transferred from the old release subdirectory 202 to 
subdirectory to 206. From there, the files may or may not be transferred to the shipped 
list file 36 of new release subdirectory 204. Also, the software release information 
manager is not operable to install modified files into the new storage area 204 to create 
a renewal release of files and directories in the release storage area. In other words, the 
files in the release storage area 204 do not create a new release of files in release area 
202. Also, contrary to the Examiner's assertion, the software release information 
manager does not update information in the release database from information in the 
inventory file in response to the step of installing modified files and directories. 

Also, contrary to the Examiner's assertion, Noble is not operable to update 
information in a released database from the build information in the inventory file as a 
result of installing modified files. The Examiner's assertion cannot be understood. 

Contrary to what the Examiner asserts, Noble does not identify differences 
between the build information in the old release subdirectory 202 and the information in 
the new release storage area 204. Subdirectories 202 and 204 are not compared. And 
the identified customize files in elements 202 are identified by reviewing the version 
number of the customize information in forms file 24 to determine whether it contains 
any customization created after the date of the remainder of the subdirectory 202 
information which is not created by Noble, but instead, is purchased from a vendor. 

It should be noted that claim 1 has been amended to recite, in essence, that the 
comparison operation of the software release information manager is configured to 
compare build information with information and the release area wherein the 
comparison generates data, including a plurality of aspects and parameters resulting 
from the comparison. 

Claim 1 also recites the details of the functions provided by the scan element, as 
well as the functions of the build area, followed by the software comprising a new 
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generic software release, and the functions required to transfer software from the scan 
element to load generic software into to a release database to define entirety of a new 
release. The Examiner cites the Noble column 7, line 5 through column 8, and line 60 
as being relevant to the recited SRIM material. The cited Noble material does not teach 
the instrumentalities used by applicants in performing the claimed functions. 

The next element recited in amended claim 1 is directed to a comparison of build 
information in the inventory file and the release of software for a current release of 
software into the release area. The last element recited in amended claim 1 relates to 
installing modified software into a release area to create the entirety of a new software 
release. It further recites the updating of software in a released database from the build 
the area in the inventory file in response to the step of installing modified files as well as 
identifying the differences between the build area and the use release area. These 
elements are not taught by Noble. Rather, Noble is exclusively related to changes in 
customized software. Applicants are exclusively interested and directed to the 
generation of new generic software. Nothing disclosed in the entirety of Noble is of any 
patentable interest whatsoever to applicants claimed modification of generic software . 

The Examiner's attention is directed to that portion of Noble, which in column 6 
lines 4 through 1 8 states in essence that the old release file 21 2 is generated by a 
vendor's installed files . This information is received from an outside vendor and stored 
in that portion of Noble designated as new release 204 shown in figure 2 and shown in 
further detail in figure 4 . 

Claim 1 has further been amended to recite: a comparison that defines: files in 
current release but not in new build area: deleted file names not in new build area: not 
in current release: new file names in new build area and not in current release: 
differences in parameters of both newly deleted files and newly added files, file 
differences, file user permissions. This further distinguishes claiml from Noble- 
Independent claims 8 and 13 have been similarly amended. This, of course, is not 
shown by Noble. 

The Examiner's attention is directed to that portion of Noble, which in column 6 
lines 4 through 1 8 states in essence that the old release file 21 2 is generated by a 
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vendor's installed files . This information is received from an outside vendor and stored 
in that portion of Noble designated as new release 204 shown in figure 2 and shown in 
further detail in figure 4 . Noble does not teach the creation of new software information 
to be incorporated into his software. Noble is exclusively limited to the generation of 
customization after having received both the new and old versions of software from an 
outside vendor. 

The following describes the essence of figure 3 of Noble. The files associated 
with an old release are stored in subdirectory 202 which includes files from a previous 
release, along with any later created end-user customizations . Each old file 20, 22, and 
24 contains an embedded file revision parameter that is generated by the revision 
control system of the outside vendor. The new release subdirectory 204 includes new 
versions of files 20, 22, and 24. New file elements 22 and 24 do not contain any user 
applied customization. New release subdirectory 204 includes a ship list 36, which 
provides a virtual representation of a new release to minimize data storage needs. With 
reference to figure 5, and step 61 , the old release is obtained by reading vendor 
supplied software. This is done during the installation of the old release. Custom copier 
210 identifies any newly created customized files contained in the old release. The user 
provides a registry of files that lists his newly created customized files. This is used in 
determining whether there are any new valid customized files in element 202. 

In general, identified new files that were not included as part of the old software 
release are considered to be customer generated files. These user generated 
customizations are copied from element 202 and entered into element 206. At this point, 
the new directory element 204 receives new hard copy of only the customization from 
element 206. Noble describes an operation in which subdirectory 202 does not contain 
any new user customization. In this case, nothing is transferred from element 202 to 
element 206, and no new customer customization is transferred to element 204 . It 
should be emphasized that the old version of the generic software is never transferred 
to the new release subdirectory 204. 

Dependent claims 3 through 7 are believed to be allowable by virtue of their 
dependency on independent claim 1 which is believed to be allowable. Therefore, a 
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detailed discussion of each of these dependent claims is not necessary. However, with 
respect to a dependent claim 7, the Examiner asserts that Noble teaches the identified 
differences recited by claim 7, in column 6, lines 63 to 67 for support. This rejection is 
not understood. A review of the cited portions of Noble indicates that Noble executes a 
compare operation to compare the difference between the new and old releases having 
the same file revision number. Applicants assert that this generic assertion does not 
preclude the claiming of the details of the differences between files etc. generated by 
the comparison. 

Dependent claim 3 is directed to applicants' release area 308 and a scan 
element 302 as well as the inventory files 310 which stores information regarding files 
and directories in the build area. The columns and lines of Noble relied on by the 
Examiner have been studied and found to be of no relevance to the instrumentalities 
recited in amended claim 3. This Noble material includes that in column 6, lines 1 
through 10 which exclusively relates to the generation of customized software. The 
applicants' disclosure is related to the generation of new releases of generic software . 

Dependent claim 4 is directed to the functions of verify element 304. The Noble 
material relied on by the Examiner has been studied and found to be of no relevance to 
amended claim 4. This includes the Noble's material in column 7, lines 1 through 50, 
column 6, lines 30 through 33 and 63 through 67 as well as column 7 lines 30 through 
45. This cited material exclusively relates to the generation of customized software . The 
applicants' disclosure is related to the generation of new releases of generic software. 

Dependent claim 5 is directed to the further details of Applicants' software 
release information manager 300 including the functions of install element 306 coupled 
to an inventory file 310. The Noble's material in column 6, lines 35 through 60 and 
column 5 lines 1 through 5 relied on by the Examiner has been studied and found to be 
of no relevance to amended claim 5. This cited material relates to the generation of 
customized software for end-users. Applicants' disclosure relates to the generation of 
generic software. 

Dependent claim 6 is directed to further details of build area 106. Column 4, lines 
40 - 55 lines of Noble relied on by the Examiner have been studied and found to be of 
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no relevance to the recitation of in amended claim 6. This cited material as nothing 
whatsoever to do with the applicants' invention. It is respectfully suggested that the 
Examiner review column 5, lines 60 through 68 which describe in detail the operation of 
Noble for customizing a new software release. As shown on flow chart figure 5, Noble is 
related to the creation of customized information for a new release. The applicants' 
disclosure is inventively different in that it is entirely limited to the generation of generic 
software for a new software release. 

Dependent claim 7 characterizes the types of information that may embody 
identified differences between old and new software. The columns and lines of Noble 
relied on by the Examiner have been studied and found to be of no relevance to the 
instrumentalities recited in amended claim 7. The cited material in column 6, lines 60 
through 63 of Noble relates to the differences between customized files. 

Independent claims 8 and 13 are comparable in scope to claim 1 and differ from 
Noble for the same reasons stated regarding claim 1 . No further discussion is 
necessary. 

Dependent claims 3-7 and 9-12 should be allowable as including the limitations 
of their independent claims 1 , 8, and 1 3 which are believed to be allowable. 

If Noble is reapplied, the Examiner is requested to indicate with specificity and 
particularity, by Noble part #, each element of Noble that allegedly corresponds to an 
element of applicants' claims, This is required by MPEP 2131 . The Examiner is 
requested to cease citing entire columns of Noble in support of an assertion that a 
element of Applicants' is taught by Noble. Compliance with this request will expedite the 
prosecution of this application. 

The Examiner is respectfully requested to call if the prosecution of the application 
can be expedited by so doing. 
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Respectfully submitted, 



Date: 25 July 2008 /Donald M. Duft/ 

SIGNATURE OF PRACTITIONER 
Donald. M. Duft, Reg. No. 17,484 
Duft Bomsen & Fishman LLP 
Telephone: (303) 786-7687 
Facsimile: (303) 786-7691 through 68 
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